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Section 1 


INTRODUCTION 


1.1 PURPOSE 


The purpose of this volume Is to present a software development 
plan for the definition, design and Implementation of the Space Station (SS) 
Payload Mission Planning System (MPS). 

This plan Is an evolving document and must be updated 
periodically as the SS design and operations concepts as well as the SS MPS 
concept evolve. 

1.2 SCOPE 


The major segments of this plan are as follows: 

Section 2. Project Technical Description . Includes an overview 
of the SS MPS and a description of its required capabilities 
Including the computer programs identified as configurable items 
with an explanation of the place and function of each within 
the system. 

Section 3, Project Activities . Presents an overview of the 
project plan and a detailed description of each development 
project activity breaking each Into lower level tasks where 
applicable. 

Section 4, Development Schedules and Manpower Requirements . 
Identifies the resources required and recommendations for the 
manner In which they should be utilized Including recommended 
schedules and estimated manpower requirements. 

Section 5, Software Development Procedures . Describes the 
practices, standards and techniques recommended for SS MPS 
Software (SW) development. 
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Section 2 


PROJECT TECHNICAL DESCRIPTION 

The SS Payload Mission Planning System (MPS) is a computer-based 
system that aids SS users and mission planning personnel In developing payload 
on-orbit operations plans and schedules. The MPS is a modularized system that 
encompasses planning functions from Initial user operations requirements 
definition to generation of executable plans and real-time replanning. The 
MPS SW functional requirements are derived from the SS MPS Functional Flow 
Concept presented and discussed in Volume II of this report. The scope of the 
SS payloads to be scheduled Include all payload operations Included within or 
attached to the SS manned base. 

A considerable portion of the SW to be utilized in the SS MPS 
was previously developed and utilized in the Spacelab <SL) Payload Mission 
Integration Planning System (MIPS) for preflight planning and real-time 
replanning for Spacelab payloads. Because of the similarity In some functions 
between the SS MPS and the SL MIPS, It was determined to be more cost 
effective to modify the SW corresponding to these functions for use In the SS 
MPS than to generate totally new SW. 

A hierarchical depiction of the computer programs Included In 
the SS MPS is presented In Figure 2-1. For the purposes of this plan it is 
assumed that each of the computer programs identified on this figure are 
classified as configurable items. The exception to this is the "Data Flow" 
block which in reality will encompass various interrelated data flow analysis 
and planning computer programs. The actual functional breakdown of the SS 
data communications system is presently inadequate for the purposes of 
function allocation to computer programs. 

The decision to develop the SS MPS in the architecture described 
— loosely coupled, interrelated computer programs — evolved based on several 
factors: 


(1) The present architecture of the SL MIPS. 

(2) The number and complexity of planning interfaces. 

(3) The ability to clearly partition functions into loosely 
related modules. 

(4) The desire for a structured modularized system that will 
present the maximum benefits in overall system flexibility, 
ability to evolve/expand and system maintenance and 
configuration control. 

A number of the SW modules identified in Figure 2-1 are 
annotated as Artificial Intelligence (AI) candidates. A description of the AI 
techniques to be utilized in these computer programs is included in the 
functional descriptions of the individual programs. Additional depth on the 
AI considerations is included in Volume II of this report. 

A functional description of each of the computer programs identified in Figure 
2-1 and included in the SS MPS is presented in Appendix A of this volume. 
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SS MPS SW HIERARCHY 

(USERS, PLNG CTR AND PLD OPS INTEGRATION CTR) 



FIGURE 2-1. SS MPS SW HIERARCHY 
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Section 3 


PROJECT ACTIVITIES 


3.1 OVERVIEW 

3.1.1 Major Activities and Formal Reviews 

The major activities of software development for the SS MPS can 
be divided into two groups: (1) those performed at the SS MPS system level 

and (2) those performed at the SW computer program (configurable item) level. 

Most major activities culminate in a formal review. System 
level activities (and the resulting formal reviews) Include: 

(1) System Requirements Definition/Design (System Specification 
Review) 

(2) System Level Simulations (System Performance Review) 

Software computer program level activities (and resulting formal 
review) Include: 

(1) Software Requirements Definition (Software Requirements 
Review) 

(2) Preliminary Program Design /Prel iminary Design Review) 

(3) Detailed Design and Analyses (Critical Design Review) 

(4) Coding and Unit Testing (No formal review required) 

(5) Module Integration and Testing (Test Procedures Review) 

(6) Computer Program Testing (Software Acceptance Review) 

A description of each of the major activities identified above 
Is presented In the following sections. The SW computer program level 
activities described above will be performed in sequence for each computer 
program individually or for SW sets -- groups of similar programs at the same 
level in the SS MPS hierarchy that for configuration control purposes may be 
developed simultaneously. 

3.1.2 Documentation 


Table 3.1-1 identifies the formal reviews required at completion 
of the major activities for the SS MPS or for each computer program or SW 
set. The purpose of the review and the documentation to be reviewed are also 
shown. 


Table 3.1-2 defines the documents required for successful 
completion of the SS MPS SW Development Project. A System Specification and 
System Simulation Report will be required for the overall SS MPS. The other 
documents listed are required for each computer program. 
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Version Description Document Describe content and capability of SAR 

delivered Software version 



3.1.3 


Definition of Computer Program Structure 


Computer program structured design (Yourdon, E. and L. 
Constantine, Strucutred Design , Yourdon and Company, Inc., 1976) Is a method 
of defining the architectural structure of a computer program using a top-down 
method of design. From the top down, a "program" consists of "modules" which 
in turn consist of "units." These terms are used with this meaning in this 
plan. 

3.2 $$ MPS SYSTEM REQUIREMENTS DEFINITION/DESIGN 

Because of the modularized nature of the SS MPS system - each 
program being loosely coupled to other programs or executives - a 
comprehensive SW system design must be performed before developing each of the 
Independent programs. The design must be updated periodically as the 
development of each of the individual programs proceed. Changes in the system 
design resulting from computer program requirements changes must be fed back, 
to any other Impacted programs. The activities performed during this phase 
consist of the requirements analysis and trade studies to determine: (1) the 
SS MPS functions to be performed, (2) how well the functions are to be 
performed, (3) how the system will be structured or segmented, <4) the 
allocation of top level requirements to individual segments (computer 
programs), and (5) the definition of system-level data base requirements. The 
SS MPS functional flows, SW hierarchy, and SW functional requirements Included 
in Volume II of this report should be used as the baseline for performing 
these tasks. 


The SS MPS system design depends on several external factors, 
most notably the SS design and operations concepts and the Interfaces with SS 
systems operations, users and user working groups. Because these factors 
will most likely be transient over the course of the SS MPS project a 
systematic design approach documenting open items and phasing SW computer 
program development based on the attainable level of requirements definition 
must be followed. 

The output of this phase Is the SS MPS System Specification 
documenting the results of the above analysis. A formal review of the System 
Specification Is required to baseline the document. This document will 
require periodic updating (formally controlled) as the SS MPS software 
development proceeds. 

3.3 SOFTWARE REQUIREMENTS DEFINITION 

Software requirements will be analyzed to completely define the 
functional, performance, interface and verification requirements of each 
computer program. This activity extracts SW requirements from the System 
Specification and derives additional detailed requirements. 
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fol lows: 


A description of each of the tasks comprising this activity 


(1) Requirements Analysis and Allocation . All system level 
requirements pertaining to an individual program are expanded to provide a 
clear definition of the functions and performance parameters for the computer 
program. 


(2) Operational Sequence Analysis . The computer program level 
functional requirements contained in the System Specification are extended to 
a lower level of detail to describe the detailed functions of the Individual 
program. The emphasis is to derive detailed requirements as they relate to 
other MPS programs. 

(3) Interface Definition . This activity involves using the 
DeMarco/Yourdon Structured Analysis techniques Including data flow 
diagramming, preparing a data dictionary of all Interface data, and creating 
process/functional descriptions. Interface analysis, human factors analysis 
and design tasks must be performed to derive the associated software 
requirements. This activity will take Into consideration partitioning 
functional requirements to minimize Interfaces, providing traceability to the 
System Specification, and providing for completeness, consistency, and 
testability of the requirements. 

(4) Participate in Walkthroughs and Reviews . This activity 
subjects the evolving requirements specifications - that is, the data flow 
diagrams and process descriptions - to review by managers, quality evaluation 
personnel, and software engineering peers. Resultant Issues and decisions 
will be documented In walkthrough reports and Internal review reports. 

(5) Finalize the Software Requirements Specification (SRS) . 

This activity Involves documenting the results of the previous analysis and 
review activities. A separate SRS will be developed for each of the computer 
programs and each SRS will contain the Interface Requirements Specification 
(IRS) for the computer program. The SRS includes textual and graphical 
descriptions of Interface Identifications and summaries, interface data, 
function inputs and outputs, requirements traceability, and qualification 
methods. 


(6) Participate in the Software Specification Review <SSR) . 
This activity involves preparing for and participating in the SSR. The data 
item to be reviewed is the SRS. 

3.4 PRELIMINARY PROGRAM DESIGN 

Preliminary program design is the process of defining the 
overall structural design at the computer program level. This process 
includes the allocation of functions to lower level program modules, 
definition of the interfaces between these modules, development of the data 
base concept and development of a verification plan. 
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follows: 


A description of each of the tasks comprising this activity 


(1) Preliminary SW Design . Computer program functions 
specified in the SRS are organized into modules, the first structural level 
below the program. Program structure and operating concepts will be defined 
in this phase and should require little variation in subsequent phases. 

Actual module design could change significantly in the detailed design and 
analysis phase. The operational concept of each program will be defined, 
specifying how the program will be controlled to accomplish its function. The 
concept of control, sequencing of executable elements, interrupt handling, and 
Input/output handling are developed at this point. Operational modes are 
defined and operational timelines developed which describe the expected 
sequence and timing of executable elements for normal and abnormal conditions. 

(2) Timing and Sizing Studies . Estimates of the time required 
to execute each executable element and the amount of memory required during 
execution will be prepared. These estimates, particularly that of time, will 
be of Importance to planned use of executable elements in the real-time 
mission replanning cycle. 

(3) Preliminary Interface Design. Interfaces between the 
computer program and external sources will be defined by types of data, data 
rates, special conditions. Interface protocol and special data Items. 

Because of the phased nature of the MPS software development this task will be 
somewhat fragmented. Computer programs that are developed first will assume 
interfaces with programs to be developed downstream. System level design will 
alleviate the problem by supplying as much detail as possible at the top level. 

(4) Data Base Design. The structure of the data base, access 
methods, updating methods, control and protection procedures will be 
determined. The phased SW development will again Impact this task. Data 
bases that are common between computer programs developed out of phase will 
most likely require iterations to complete their design. System level data 
base requirements will be as detailed as possible to alleviate this problem. 

(5) Participate In Walkthroughs And Reviews. This activity 
subjects the evolving FDD and operation and support documentation to review by 
managers, quality evaluation personnel, and software engineering peers. 
Resultant issues and decisions will be documented in walkthrough reports and 
internal review reports. 

(6) Establish the Software Development Library (SDL). This 
activity begins with the entry of the customer-approved specification (SRS) 
into the SDL. The SDL will contain documentation, tools, and evolving 
software needed during the design, coding, and testing of the software. (See 
paragraph 5.2.) 
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(7) Finalize Functional Design Document (FDD) . This activity 
incorporates the results of the design and review activities above to produce 
a deliverable FDD. 

(8) Test Planning. A preliminary Software Test Plan (STP) for 
each computer program will be developed. 

(9) Participate In Preliminary Design Review (PDR) . This 
activity Involves preparing for and participating in the software PDR, which 
is a formal review. The data items to be reviewed are the FDD and preliminary 
STP. 


3.5 DETAILED DESIGN AND ANALYSIS 


The technical objectives for this phase are to complete and 
review the design of each computer program, and the computer program 
Interfaces. 


follows: 


A description of each of the tasks comprising this activity 


(1) Analysis . This activity includes equation or algorithm 
derivation, data base content analysis, data storage and access analysis, 
throughput analysis and software design analysis. 

(2) Interface Design. Interfaces designed during preliminary 
design will be finalized and changes coordinated on both sides of the 
interface. 


(3) Software Modeling. This activity consists of experimental 
coding of the functions to be evaluated and dummy representations of the 
interfacing elements not required to verify the design solutions. 

(4) Software Operation Design. Includes support of initiation 
and operation of the computer program. Initiation involves activating the 
software, controlling its execution and operating backup configurations. 
Operation design involves the detailed definition of all interactions with 
human users of the software, including display formats, command inputs, 
operational restrictions and error conditions. 

(5) Detailed SW Design. Develop a detailed logic flow for all 
levels of SW in a top down manner. 

(6) Create Software Development Files (SDFs). SDFs will be 
created to correspond to all units now defined as a result of the 
decomposition of the higher level elements. Each SDF will correspond to a 
unit or logically related group of units. (See paragraph 5.3.) 

(7) Develop A Software Test Description (STD). This activity 
will produce an STD for each computer program to describe the test cases for 
each formal test. Descriptions include initialization information, input 
data, intermediate test results, output data, and criteria for evaluating 
results. These will be submitted as a part of the CDR data package, plus a 
finalized version of the STP. 


3-7 



(8) Prepare Documentation For Unit Test Cases And Integration 
Test Cases. This activity will Identify the requirements, responsibilities, 
and schedule. General Information had previously been included in the STP. 
Since module and unit identifications will be available at the time of this 
activity, details specific to each element can be documented. This activity 
will also describe inputs, expected results, and evaluation criteria for the 
informal test cases. 

(9) Participate In Walkthrough and Reviews. This activity 
subjects the evolving detailed design to review by managers, quality 
evaluation personnel, and software engineering peers. Allocation of 
requirements to the modules and units will be assessed. Projected sizing and 
timing budgets and margins will be reviewed. As in the preliminary design 
activity an iteration In module design may be warranted if allocated budgets 
and projected budgets have significant variations. -The walkthroughs will 
assist In the detection of Interface and implementation design problems. The 
walkthroughs will occur after a significant amount of design has been produced 
but early enough so that detected flaws can be corrected before major rework 
is required. 


< 10) Prepare the Software Detailed Design Document (SDOD). This 
activity Incorporates the results of the design and review activities above to 
produce a deliverable SDDD for each computer program. Included in each SDOD 
will be the Interface Design Document ( IDD) and Data Base Design Document 
(DBDD). The SDDDs will be submitted as a part of the CDR data package. 

(11) Participate in the Critical Design Review . This activity 
Involves preparing for and participating in the CDR, which is a formal 
review. The data Items to be reviewed are the SDDD, STP, and STD. 

3.6 COOING AND UNIT TESTING 


Units will be coded in a top-down manner and each will be tested 
for verification of its processing, data manipulations, and error handling. 

A description of each of the tasks comprising this activity follows: 

(1) Code Units in a Top-Down Manner . Each unit will be coded 
per the coding standards specified in paragraph 5.5. Some coding standards 
will be unique to a computer program. This uniqueness will be due to 
pecularities of each of the programs, software development facilities, the 
System Requirements and the run time operating systems. Any exceptions made 
to top-down coding will be made to address critical units. 

(2) Prepare Unit Test Procedures. This activity will define 
the test procedures for unit testing including the objectives of the test 
case, the test methods, inputs, and expected outputs. 

(3) Perform Unit Tests . This activity will involve obtaining 
error-free compilations, debugging in-line to allow static analysis and 
breakpointing, stubbing of called units, and some integrating of modules to 
ensure consistent testing. 
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(4) Update the SDFs. This activity involves recording the 
results of the unit tests and inserting these test results and the current 
source code listings into the corresponding SDFs. 

(5) Prepare Module Level Integration Test Procedures. This 
activity produces documentation for the Module Level Integration Test 
Procedures including objectives, test methods, inputs, and expected outputs of 
the testing. 


(6) Prepare A Preliminary Software Test Procedure (STPR) For 
Each Computer Program. This activity documents the procedures to be used for 
formal testing, that is, for computer program testing. The documentation 
Includes pretest procedures, step-by-step procedures, and the procedures to be 
used for data reduction and data analysis. 

(7) Participate In Walkthroughs and Reviews. This activity 
will subject the unit with its hardcopy code listing and test results to 
review by managers, software quality evaluation personnel and software 
engineering peers. This activity will assist in detecting Interface and flow 
problems, inconsistencies with coding standards, and deficiencies In 
testing. Any Issues or decisions that result from the review will be recorded 
in the SDF. 

(8) Develop Operation and Support Documentation . This activity 
will produce the Software User's Manual (SUM) and Computer System Operator's 
Manual (CSOM) for each computer program. 

3.7 MODULE INTEGRATION AND TESTING 


Units will be Integrated Into modules tested in accordance with 
the module integration test cases and Module Integration Test Procedures. 

A description of each of the tasks comprising this activity 

follows: 


(1) Integrate Units Into Modules. Units will be integrated to 
form higher level elements so that testing of the aggregates may be 
performed. The units will also be Integrated to form the computer programs; 
however, testing of the computer programs will occur during the next major 
activity. 


(2) Test Modules . Tests will be performed on the modules 
according to the documented test cases and test procedures. The testing will 
produce hardcopy outputs onto which annotations will be marked to show where 
the objectives and requirements have been met. Discrepancies will be 
documented. Recommendations for corrective action and retest will be made. 

<3> Assess Memory Use and Processing Times. This activity will 
contrast memory and processing time allocations made during the design 
activities with memory and processing time values obtained when aggregates for 
units were tested together. Also assessed will be any required system 
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resources that may differ from earlier specifications. Any necessary changes 
will be made to the documentation to reflect the new assessments of memory and 
processing time requirements and any new system resource requirements. 

(4) Record The Test results. Module Integration test results 
will be recorded In the format given In paragraph 5.4. 

(5) Perform Needed Corrections and Regression Testing. 
Corrections will be made as necessary to design documentation and code. 
Required regression testing will be performed. The SDFs that correspond to 
the units that have undergone design documentation or coding changes will be 
updated. 


(6) Finalize The STPRs For Each Unit. The preliminary STPRs 
for each computer program prepared during the previous major activity will be 
finalized. 


(7) Participate In Walkthroughs And Reviews. This activity 
subjects the module Integration test results, computer program formal test 
procedures and evolving SUMs and CSOMs to review by managers, software quality 
evaluation personnel and software engineering peers. Resultant issues and 
decisions will be documented in walkthrough reports and internal review 
reports . 


(8) Update the SUM and CSOMs. The evolving versions of the SUM 
and CSOM for an computer program will be updated with any known details. 

<9) Participate In The Test Procedures Review (TPR). This 
activity involves preparing for and participating In the TPR, which Is a 
formal review. The data Items to be reviewed are the module integration tests 
results, STPRs for each computer program and the evolving SUM and CSOM for 
each computer program. 

3.8 * COMPUTER PROGRAM TESTING 

The computer programs are tested In accordance with formal test 
documentation. Then all software and documentation Is readied for audit and 
delivery or baselining for use. 

A description of each of the tasks comprising the activity 

follows: 


(1) Test Computer Programs . This activity involves testing 
each program In accordance with the formal test documentation which includes 
the STP, STD, and STPR. Testing will be performed by individuals who are 
independent from the developers. 

(2) Prepare SW Test Report (STR). Record the formal test 
results and prepare a Software Test Report (STR) containing a summary of the 
tests, test history, results of each formal test, test result evaluations and 
recommendations, and deviations. This test reporting will be performed by 
individuals independent from the developers. 
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(3) Perform Corrections and Retest . Corrections will be made 
as necessary to design documentation and code. Required retesting will be 
performed . 


(4) Prepare a Version Description Document (VDD) for each 
Computer Program . This activity involves identifying the exact version of 
each computer program and the interim changes that occur between versions. 
The VDD is a living document Intended to maintain a change history for the 
computer program and allow users of the software to identify changes made 
between different releases. 

(5) Finalize The SUM and CSOM For Each Computer Program. The 
completed versions of the SUM and CSOM for each computer program will be 
prepared. 


(6) Participate in Walkthroughs and Reviews. This activity 
will subject the completed software and documentation to review by managers, 
software quality evaluation personnel, and software engineering peers. 

(7) Participate in Software Acceptance Review (SAR) . Formal 
test results in the STR will be reviewed to verify that the computer program 
was successfully tested. A check will be made to see if the requirements of 
the SRS have been met. The VDD will be reviewed to make sure it reflects an 
accurate technical description of the computer program. The final versions of 
the SUM and CSOM will be evaluated with respect to how well they address 
operation and support of the computer system. 

(8) Prepare Computer Program For Delivery . The deliverable 
versions of source and object code for each computer program will be prepared 
for delivery in accordance with the requirements stated in the SRS for the 
computer program. . 

3.9 UNIQUE ACTIVITIES IN SS MPS DEVELOPMENT (COMPUTER PROGRAM LEVEL) 

The following activities are unique to one or more of the SS MPS 
computer programs. 

3.9.1 Prototyping 

This activity is performed prior to Software Requirements 
Specification. Prototyping provides working systems/subsystems at a gross 
operational level to support implementation feasibility. The end product of 
prototyping is a set of well defined requirements. For several software 
modules in the MPS system, the cost of prototyping is likely to be much less 
than the cost associated with requirements redefinition late in the 
development cycle. 

Several software modules have been recommended for prototyping 
in the LISP 1 anguage/Symbol i cs machine environment. This environment affords 
more operator flexibility and time savings than conventional hardware/software 
environments. 
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SS MPS SIMULATIONS AND PERFORMANCE REVIEW 


After each computer program has been acceptance tested according 
to formal test documentation, overall system simulations will be conducted to 
verify the performance of the SS MPS. Simulations will consist of various 
payload complement test cases. At the completion of the simulations a SS MPS 
performance review will be held. 

A description of each of the tasks comprising this activity follows: 

(1) Development Simulation Plans. This activity produces a 
Simulation Plan which identifies the requirements responsibilities, and 
schedules for the Simulations. 

• (2) Develop A Simulation Description. This activity will 

produce a description to describe the payload complement test cases. 
Descriptions Include Input data, intermediate results, output data and 
criteria for evaluating results. 

(3) Perform SS MPS Simulations. This activity consists of 
performing a Simulation of the overall SS MPS according to the documented 
Simulation Description. The Simulation will produce hardcopy outputs onto 
which annotations will be marked to show where the objectives and requirements 
have been met. Discrepancies will be documented. Recommendations for 
corrective action and retest will be made. 

(4) Document Results. The results of the Simulation will be 
documented in a Simulation Report to be reviewed at the System Level 
Performance review. 

(5) Participate In Performance Review. Simulation results will 
be reviewed to verify that the MPS performed successfully. Open Items will be 
documented as will any required iterations in the MPS development. 
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Section 4 


DEVELOPMENT SCHEDULES AND MANPOWER REQUIREMENTS 

The estimated cost of the SS MPS project In terms of manpower 
and schedule Is presented In this section. The approach to cost estimating 

was to group the computer programs Identified in Section 2 into the SW Sets 

defined in Table 4-1 based on similarities in computer program type. 
Interfaces, AI recommendations and SW hierarchy. The cost of each of these 
sets was estimated by use of the Constructive Cost Model (COCOMO). The effort 

required for prototyping, system level design and system level testing was 

estimated separately. 

4.1 METHODOLOGY AND ASSUMPTIONS 


The COCOMO estimating procedure Is driven by program size 
(lines of code) and various cost drivers as described in the following 
paragraphs. 


4.1.1 Lines Of Code 


.The lines of code estimates for each new computer program (see 
Table 4-1) were arrived at by allocating functions to each computer program 
(see Appendix A), estimating the lines of code for each function and summing 
these to arrive at the total computer program estimate. 

The original lines of code for the modified SL MIPS computer 
programs were taken from the SL MIPS Data Base presented in Volume II, 

Appendix A. Design, coding and integration modification factors were 
estimated subjectively based on the number of functions to be retained from 
the reused code and the number of new functions to be added. 

4.1.2 Software Cost Drivers 

The various cost drivers employed by COCOMO are shown in Figure 
4. 1.2-1 along with the ratings assumed for each of the SS MPS SW Sets. 
Definitions of each of the cost drivers and how they are applied in the cost 
estimating process can be found in Software Engineering Economics . Barry 
Boehm; Prentice-Hall, Inc.; Englewood Cliffs, N. J.; 1981. 

4.2 MANPOWER REQUIREMENTS 

The manpower requirements are an output of COCOMO for each SW 
Set development effort with manual adjustments made for prototyping, system 
level design and system level simulations and performance reviews. 

4.2.1 SW Set Manpower Requirements 

The number of manmonths per SW Set Phase required to 
successfully complete the SS MPS project is illustrated for the individual SW 
Sets in Figure 4.2. 1-1. An activity distribution of manpower corresponding to 
this phase distribution is included in Appendix B. 
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TABLE 4-1 SW SET GROUPINGS AND LINES OF CODE ESTIMATES 


NEW SOFTWARE 

SYSTEM EXECUTIVES (PHASE I) 
USER MPS EXEC 
PLANNING CENTER MPS EXEC 
POIC MPS EXEC 

SYSTEM EXECUTIVES (PHASE II) 
USER MPS EXEC 
PLANNING CENTER MPS EXEC 
POIC MPS EXEC 

SPECIAL OBS OPPS EXECUTIVES 
TOP LEVEL 
ATMOS PHYS 
SOLAR 

EARTH SITE 
PLASMA PHYSICS 
CELESTIAL 
EDITOR EXECUTIVES 
- MODEL EDITOR EXEC 
OBS OPPS EDITOR EXEC 
SCHEDULER EXEC 
RE-SCHEDULER 
URDB I/F 
COMMAND PLANNER 
OUTPUT PROCESSOR EXEC 
NEW TIMELINE ANALYSIS SOFTWARE 
MDL EXTRACT 
MDL COMPARE 
TL COMPARE 
TL MERGE 
PCAP DELTAS 
SUMMARY PCAP 


ESTIMATED 


LINES 

OF CODE 

MODULE 

SET 


37,000 

9,000 

14,000 

14,000 

55,000 

15,000 

20,000 

20,000 

42,000 

22,000 


4,000 


4,000 

4,000 


4,000 


4,000 

18,000 

6,000 


7.000 

5.000 

36.000 

41 .000 

10.000 
8,000 

53,000 

4,000 

4.000 

6.000 
6,000 
8,000 

25,000 



TOTAL 

300,000 
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TABLE 4-1. SW SET GROUPINGS AND LINES OF CODE ESTIMATES (CONT'D) 


MODIFIED SL MIPS MODULES 

LINES OF CODE 
MODULE SET 

ESTIMATED 
EQUIVALENT 
NEW LINES 

ORBIT ANALYSIS 

63,209 

20,525 

ASEP 

14,191 


ATMOS 

1,650 


BORB 

2,100 


CAVA 

20,072 


ESAL 

1,850 


ESDAT 

700 


LTO 

351 


RADI2 

8,060 


STAR 

2,054 


TANRAY 

1,625 


TARGEN 

10,556 


TIMELINE ANALYSIS 

173,200 

61,395 

ESP 

90,000 


PCAP 

27,000 


PTS 

6,200 


TAE 

10,000 


VME 

40,000 


DATA FLOW ANALYSIS 

164,224 

75,461 

PROFILE 

5,031 


MISSION WINDOWS 

16,608 


ONBOARD RECORDER SCHEDULAR 

15,587 


POSSIBLE FORMATS 

2,630 


FORMAT SCHEDULAR 

7,908 


POSSIBLE POCC CONFIGURATIONS 

9,396 


POCC CONFIGURATION SCHEDULAR 

5,555 


PLAYBACK SCHEDULAR 

16,498 


INTERACTIVE DATA UPDATE SYSTEM 

31,790 


VERIFICATION 

8,186 


COMPARE TDRS 

580 


COMPARE MODELS 

2,072 


DATA MANAGEMENT CHECKLIST 

5,857 


DATA SCHEDULE FILE 

29,412 


ANTENNA DISPLAY 

4,056 


IDMS LIBRARY 

3,058 



TOTAL 


400,633 157,381 
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Because of the uncertainties of the values of the various cost 
drivers used in the SS MPS cost estimating procedure an analysis was 
performed to identify the sensitivity of the estimated outputs to variance in 
the assumed cost drivers. A representative SW Set, the Re-Scheduler, was 
chosen as an example. Five of the cost drivers were analyzed and the change 
in manpower corresponding to changes in these drivers is presented in Figure 
4.2. 1-2. The baseline assumptions are the same as shown in Figure 4. 1.2-1 
except for the particular driver being analyzed. 

From the results it is obvious that the overall estimate 
accuracy relies heavily on the accuracy of the input cost drivers, and the SW 
cost estimates must be kept current as more definition of the project is 
attained. 

4.2.2 Manpower Requirements Summary 

A top level summary of the manpower required to successfully 
complete the SS MPS project is presented in Table 4. 2. 2-1. The summary 
Includes the COCOMO outputs of Appendix B adjusted for prototyping and system 
level activities. The total estimated manpower requirement is 4841 manmonths. 

An estimate ran under the same assumptions and excluding the 
benefit of the SL MIPS software yielded an estimated manpower requirement of 
9693 manmonths. 
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FIGURE 4. 1.2-1. SOFTWARE COST DRIVER RATINGS (COCOMO INPUT PARAMETERS) 
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FIGURE 4. 2. 1-1. MANPOWER PER SW SET PHASE (CONT'D) 
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FIGURE 4.2. 1-1. MANPOWER PER SW SET PHASE (CONT'P) 







TABLE 4. 2. 2-1. MANPOWER REQUIREMENTS SUMMARY 



DURATION 

MANPOWER 

MAN- 

ACTIVITIES 

(MONTHS) 

(MANMONTHS) 

LOADING 

MPS SYSTEM DESIGN 

8 

96 

12 

MPS SYSTEM SIMULATIONS/ 
PERFORMANCE REVIEW 

15 

360 

24 

SW SETS DEVELOPMENT 

A - SPECIAL OBS OPPS EXECS 

28 

388 

13.9 

B - URDB I/F 

53 

.498 

9.4 

C - EDITOR EXECS 

21 

152 

7.2 

D - RESCHEDULER 

46 

419 

9.1 

E - SYSTEM EXECS (PHASE I) 

40 

416 

10.4 

F - SYSTEM EXECS (PHASE II) 

57 

682 

12.0 

G - COMMAND PLANNER 

16 

67 

4.2 

H - NEW CONVENTIONAL TL SW 

31 

498 

16.1 

I - MODIFIED TIMELINE SW 

30 

467 

15.6 

J - MODIFIED ORBIT SW 

20 

123 

6.2 

K - MODIFIED DATA FLOW SW 

33 

625 

18.9 

L - OUTPUT PROCESSOR EXEC 

15 

50 

4841 

3.3 
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4.3 


SCHEDULES 


4.3.1 SW Set Schedules 

An activity schedule for each SW Set project phase is included 
in this section. The schedules are presented separately and include only 
delta times. The actual phasing of the SW Set development is arrived at 
subjectively and is discussed in Section 4.3.2. 

The SW Set schedules assume that all the computer programs 
within a particular set all work toward the same project milestones SRR, PDR, 
CDR, etc. Further granularity can be obtained by scheduling activities to the 
computer program level, if desired, as better definition of the project is 
obtained. Figure 4.3. 1-1 depicts the schedules for the twelve SW sets. 

In determining these schedules the COCOMO output Included in 
Appendix B was used as a basis. Subjective adjustments were made to the 
COCOMO output based on the estimators experience. In particular, the duration 
of the COCOMO programming phase output, which Includes detailed design, 
analysis, coding, and unit testing as shown in Figure 4.3. 1-1, was arbitrarily 
lengthened to reduce peak manpower levels. 

4.3.2 Top Level SS MPS Schedule 

The recommended SS MPS Top Level Development schedule is shown 
in Figure 4. 3. 2-1. This schedule was arrived at subjectively based on the 
evaluation of each SW Set against several factors and considering the overall 
SSP milestones. Figure 4. 3.2-2 presents the criteria that were considered and 
the rating of each set versus that criteria. Obviously development lead time 
for the four SW Sets that require prototyping was the overriding factor and 
requires that development of these SW Sets begin as soon as possible. These 
SW Sets have sufficient requirements definition to begin prototyping 
concurrent with the SS MPS system level design activity. It is also 
recommended to begin development of A-Special Obs Opps Executives, J-Modified 
SL MIPS Orbit Analysis SW and I-Modified SL MIPS Timeline SW as soon as the 
system design activity is completed because of three factors: (1) the initial 
manloading of the SW sets to be prototyped is relatively low, (2) requirements 
definition for the modified SW should be relatively high and (3) the 
dependency on SS operations and design concepts for the modified SW is low to 
moderate. The remaining activities should be phased in based on better 
definition of the SS operations and design concepts and MPS concept. As these 
become more firm, better decisions on the actual phasing of the SW development 
can be made. For budgetary purposes an estimate of the required manloading 
for the first two years of the project was made and is presented in Table 
4. 3. 2-1, based on the recommended top level schedule in Figure 4. 3. 2-1. No 
attempt was made to provide a distribution of manloading for the remainder of 
the project because of the instabilities of the long term schedule. If the 
project proceeds as shown on the top level schedule the manloading for the 
remaining 40 months of the project would average an estimated 99 men. 
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FIGURE 4. 3. 1-1. SW SET DEVELOPMENT SCHEDULES 
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SW SET DEVELOPMENT SCHEDULES (CONT'D) 
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FIGURE 4.3. 1-1. SW SET DEVELOPMENT SCHEDULES (CONT’D) 
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FIGURE 4. 3. 2-1. SS MPS TOP LEVEL DEVELOPMENT SCHEDULE 
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FIGURE 4. 3. 2-2. SW SET PHASING CRITERIA 








Because of the uncertainties in the SSP overall schedule and the amount of 
time the SS MPS must be in place before on-orbit payload operations begin, the 
actual MPS schedule that will be followed is uncertain. The estimates 
included in this plan are made to scope the magnitude of the project and to 
provide input for budgetary decisions. As the SS MPS project progresses 
periodic updates to this schedule will be required. 


TABLE 4. 3. 2-1 MANPOWER LOADING ESTIMATES 


FISCAL YR-QUARTER 

1988- 1 
2 

3 

4 

1989- 1 
2 

3 

4 


MANPOWER REQUIRED 

22 

22 

22 

23 

28 

42 

56 

73 
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Section 5 


SOFTWARE DEVELOPMENT PROCEDURES 

5.1 SW TECHNIQUES AND METHODOLOGIES 

The following paragraphs describe the software development 
techniques and methodologies recommended for use on the SS MPS project. 

5.1.1 Structured Analysis for Software Requirements 

Structured Analysis (SA) Is a method of modeling a system using 
the DeMarco/Yourdon method of data flow diagramming, process/function 
descriptions, and data dictionary definitions. This method views a system by 
the data flows and interfaces and the functions performed upon the data. 

This method is a top-down approach where each process/function 
can be further defined into subprocesses/subfunctions. Also, the data flows 
(Interfaces) can be further divided into subflows. All information is 
maintained in the data dictionary and process/function descriptions 
(minispecs) for incorporation into the Software Requirements Specification. 

5.1.2 Structured Design for Software Top Level Design 

Structured Design (SD), developed by Yourdon and Constantine, is a method of 
defining the architectural structure of a software system using a top-down 
method of design. Each module of a system is defined; its interfaces, calling 
sequence, and location in the hierarchy are all evident using this method. SD 
also provides sophisticated rules which can be Implemented using this method, 
allowing a designer to; 

(1) Minimize data coupling (minimize interfaces) 

(2) Maximize module cohesion (keep the functions isolated) 

(3) Minimize duplicate code 

(4) Separate working modules from the management modules 

(5) Simplify implementation 

(6) Balance the system 

5.1.3 PPL for Software Detailed Design 

Program Design Language (PDL) will be the method used for 
detailed design. PDL is a software tool (see paragraph 5.6) providing a 
structured English-type language for describing the content of a module or 
unit. The PDL follows certain rules for describing implementation structure, 
formatting, and interface descriptions. 

5.1.4 Standard for Code Development 

Code will be developed in a top-down manner consistent with the 
standards provided in section 5.5. 
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5.1.5 


Standard for Unit Testing 


Unit testing will conform to the Informal test plans, where each 
unit will be tested individually or within groups to demonstrate the 
Implementation meets both the design and requirements. 

5.1.6 Standard for Module and Computer Program Integration and Testing 

All testing will be done in a top-down manner, unless the 
criticality of a set of units are such that bottom-up or conglomerate testing 
would be justified. Each unit will be added in a systematic way such that the 
executive units are tested first, stubbing out the lower levels, until all 
units are integrated and tested for the full computer program. 

5.1.7 Walkthroughs 

Well planned internal walkthroughs will be scheduled during 
requirements analysis, top level design, detailed design, code and unit test. 
These walkthroughs will consist of Software Quality Assurance (SQA) and a set 
of software development peers whose expertise will help ensure the correct 
Implementation and evaluate the design and design trade-offs. The results of 
these walkthroughs will be recorded and become part of the software 
development files to track the design decisions and implementation directions. 

5.2 SOFTWARE DEVELOPMENT LIBRARY 


The SDL will be established during the Preliminary Design 
activity. The library will consist of a collection of library units 
established and controlled at each of the facilities used during development 
and test of the software. 

Each library unit will contain the tools, documentation, and 
source and object code associated with the computer program and phase of 
development. 


Control procedures for each unit comprising the SDL will be 
thorough and consistent. In cases where duplication exists the unit 
controlling the master will have been identified. 

The following activities will ensure a controlled SDL. 

ESTABLISHMENT OF THE SDL 

(1) The library unit of each facility will be identified, 
including its location, hardware host, storage media, and administrator. 

(2) The planned contents of the library unit will be 
identified, including software tools, documentation, and source and object 
code. At this point, where duplication will exist, the controlling library 
unit will be identified. 

(3) Current contents of each library unit will be inventoried. 

A controlled list of current contents will be maintained for each library unit. 
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(4) The naming/numbering schemes for directories, files, data 
bases, procedures, etc., used by each library unit will be established and 
published. 


(5) The backup procedures and responsibilities will be 

identified. 

(6) All media associated with the library unit will be 
identified and labeled consistent with the release documentation to which it 
corresponds. 


CONTROL OF THE SDL 

(1) User accounts will be established according to library 
access authorization. Users who have accounts on the system, but are not 
authorized to modify or access the library elements, will not have privileges 
associated with their account that would allow them to do so. 

(2) Unauthorized use of accounts that have privileges to access 
and/or modify the library elements will be precluded by the use of passwords. 

(3) Where limited access to library elements is authorized, 
access control lists will be maintained for the files so that groups of users 
will have varying privileges. For example, access control lists may allow all 
users to read the file, but only the person responsible for the library unit 
to write to the file. 

5.3 SOFTWARE DEVELOPMENT FILES 


Software Development files (SDFs) will be maintained for all 
computer programs. 

5.3.1 Benefits of the Use of SDFs 


SDFs provide a means for maintaining software in a manner that 
is visible, auditable, and consistent across the software development effort. 
A focal point is established for all information relating to the design, 
implementation, and unit test of all software elements. The SDFs form the 
primary review items during walkthroughs and other internal review procedures 
and the primary management tool for monitoring progress during software 
development. Documentation Included in the SDFs is current and available for 
incorporation into the deliverable data items. 

5.3.2 Responsibility for Maintaining SDFs 

Every unit comprising the SS MPS will have a corresponding SDF, 
though not necessarily in a one-to-one correspondence. One SDF may serve a 
logically related group of units, he SDF will be created and maintained to a 
current status by the programmer responsible for the software served by the 
SDF. 
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5.3.3 


Creation and Maintenance of SDFs 


SDFs are created during the Detailed Design phase of software 
development, after the top level modules have been decomposed Into lower level 
units. 

The SDFs will be reviewed by functional and project management 
and by Software Quality Assurance personnel. Following each event that causes 
a change to information in the SDF, such as a walkthrough or a unit test, the 
responsible programmer will update the SDF in a timely manner. 

The SDF is a working document (preferably computerized) used 
during development and test but not maintained after completion of integration 
and test. SDFs will be retained by the functional and software development 
organization for historical information. 

5.3.4 Contents and Format of the SDFs 


The SDF for each unit or logically related group of units will 
be maintained with the sections described below. Since some of the data that 
goes into the SDF, such as data flow diagrams and current source code, will be 
maintained in the Software Development Library, that data may be referenced in 
the SDF rather than duplicated. However, prior to a review or audit, the 
responsible programmer will obtain a hard copy of the current version of all 
referenced data to facilitate the review or audit. 

The SDFs will address the following: 

(a) schedule 

<b) status information 

(c) unit requirements 

<d) design considerations and constraints 

(e) code listing 

(f) test documentation 

These are addressed in the format below. 

COVER SHEETS SECTION 
Progress Table 

This table indicates the schedule and status information 
relative to the schedule with sign-off blocks for each milestone enumerated. 

Review Items List 

The list Identifies deficiencies found in the developing 
software and the engineering responses to those items listed. 

Change Log 

This log reports all the changes made to the software after the 
internal baseline has been established. 
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Walkthrough Reports 


This report documents the findings during each walkthrough. 

REQUIREMENTS SECTION 

This section contains unit requirements including interface 
requirements that are allocated to the software served by the SDF. 

Requirements changes which evolve during the software development process will 
be documented in this section. 

DESIGN DESCRIPTION SECTION 

This section Includes an overview of function detailed design, 
data base design and interfaces. Any design considerations and constraints 
will be noted. This section will contain design representation of the 
software in the form of Program Design Language (PDL) and/or structure charts. 

CODE LISTING SECTION 

This section will contain a current listing of the source code. 
It will also contain a reference (filename, directory, and version number) to 
the last reviewed source code. 

UNIT TEST SECTION 

This section includes the test methods, cases, tools, and 
startup conditions for informal testing of the software served by the SDF. 
Where the SDF corresponds not to a unit but a logical group of units, the test 
procedures identified here will pertain to the group of units. See paragraph 
5.4 for the format of unit test cases and procedures documentation. 

UNIT TEST RESULTS SECTION 

This section includes the test results and verification that the 
testing was successfully completed. See paragraph 5.4 for the format of unit 
test results documentation. 

PROBLEM REPORTS SECTION 

This section contains copies of all Software Discrepancy Reports 
(SDRs) generated after the software served by the SDF has been baselined 
internally. 


NOTES SECTION 

This section contains any other information, such as memos or 
records of discussion, that may provide useful information about the software. 

5.4 DOCUMENTATION FORMATS FOR INFORMAL TESTS 


Informal tests are performed during the Coding and Unit Testing 
and Module Integration and Testing phases of the software development cycle. 
Formal tests are tests performed during the Computer Program Testing phase of 
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the software development cycle. Formats for the documentation of formal tests 
are recommended to be defined by appropriate Space Station program data 
requirements for the Software Test Plan (STP), Software Test Description 
(STD), Software Test Procedure (STPR), and Software Test Report (STR). 


Recommended formats for informal test documentation are 
described in paragraphs 5.4.1 through 5.4.6. 


Unit test documentation will be kept in the SDF that serves the 
unit. Module Integration and Test documentation will be kept, along with the 
Unit Test documentation, in the SDF that serves that unit belonging to the 
module which has, among all units for the module, the lowest numbered 
identifier. 


5.4.1 


5.4.2 


Unit Test Plan/Description 


SECTION 


Identification 

Reference 


SECTION 
Schedules and 
Responsibilities 

Test Cases 


Support Requirements 


Unit Test Procedures 
SECTION 


Identification 

Objective 

Test Method 

Inputs 

Outputs 

Support 


CONTENTS 

Identifies the software being tested. 
Identifies the documents essential to 
an understanding of the test effort. 

CONTENTS 

Identifies those responsible for 
conducting the tests and the schedules 
to be followed. 

Identifies test cases 1 through X and 
provides, for each, a summary, 
objectives, requirements to be verified 
by the test case, test methods, and 
acceptance criteria. 

Identifies test tools and test drivers 
required. 


CONTENTS 


Identifies the software being tested. 
Identifies the objective of the test 
case. 

Identifies the test environment and 
step-by-step test procedure. 
Identifies the test inputs. 

Identifies the expected outputs. 
Identifies any required test tools or 
test drivers for the test case. 


NOTE: Test procedures will be required for each of the test 

cases identified in the test cases documentation. 
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5.4.3 


Unit Test Report 


SECTION CONTENTS 


Identification 

Summary 

Test Results 


Problems 


Identifies the software being tested. 
Provides a summary of the test results 
for the test case. 

Provides output with annotations to 
indicate where the objectives and 
requirements are met. 

Identifies and provides an analysis of 
any deviations from the expected 
output. Also included are 
recommendations for corrective action 
and retest. 


NOTE: Test case results will be required for each of the test 

cases identified in the test cases documentation. 


5.4.4 


Module Integration Test Cases 


The format and required content will be the same as for unit 
test cases. See paragraph 5.4.1 above. 

5.4.5 Module Integration/Test Procedures 

The format and required content will be the same as for unit 
procedures. See paragraph 5.4.2 above. 

5.4.6 Module Integration Test Results 


The format and required content will be the same as for unit 
test results. See paragraph 5.4.3 above. 


5.5 DESIGN AND CODING STANDARDS 


All computer programs will be designed using the top-down 
approach of the Yourdon Structured Design Methodology, and will be coded in a 
top-down manner using a Higher Order language (HOL). In general, all new 
software will be coded in ADA consistent with Space Station program 
requirements. 


Design, coding, and commenting standards are listed below. In 
cases where a particular standard cannot be implemented in the particular HOL, 
a convention similar in intent will be used. The language peculiar standards 
to be applied to the coding of individual computer programs will be stated in 
the SRS for the computer programs. 

Design Standards 

Structure Charts shall be used to show the hierarchical 
structure of the design. 
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Coding Standards 


(1) Each unit shall perform a single function. As a goal, the 
average number of executable lines per unit shall not exceed 50, with no 
single unit having more than 100 executable lines of code. 

(2) All units shall be comprised of a prologue, declarative 
statements, and executable statements with comments. In that order. 

(3) Modification of a unit's code during execution shall not be 

permitted. 

(4) Except for error exits, each routine shall have a single 
entry point and a single exit point. 

(5) Constants will not be hard-coded In the body of the code 
but will be defined and assigned a value In the declarations section. 

(6) Meaningful names shall be used for constants, variables, 
functions, and other program elements so that source code listings are 
readable. 


(7) Each line of source code shall contain, at most, one 
executable statement. 

(8) Nesting beyond five levels shall be avoided. 

(9) Mixed mode operations (Mixing Integers and Floating Point) 
shall be avoided; however. If It Is necessary to use them, their use shall be 
documented by conspicuous comments In the source code. 

(10) Error and diagnostic messages will be presented In a 
uniform manner throughout the units and be sufficiently self-explanatory that 
table hook-ups are not required In order to Interpret the message. 

(11) Coding conventions will be consistent among all units. 

Commenting Standards 

(1) Paragraphing, blocking by blank lines, and Indenting shall 
be used to enhance the readability of the code. 

(2) Comments shall be set off from the executable source code 
In a uniform manner. 

(3) The following details shall be commented In the prologue 
section of each program/module/unit: 

o Program/module/unit creation date 

o Date of last revision, revision number, problem report 
title and number associated with the change 
o Programmer name and department responsible for the unit 
o Unit's purpose and how it works 
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o The PDL generated during detailed design for the unit 
in comment form 

o Functions, performance requirements and external 

interfaces for the computer program the unit helps 
implement 

o Other units called and the calling sequence 
o Data files used including the file name, usage 

(input, output, or input/output) and summary of use 
o Use of global variables, local variables, registers 
and memory locations 
o Any special processing or tasks 

o Error conditions for which the code provides 

(4) The beginning of executable code shall be Indicated by a 
comment such as "START OF PROGRAM EXECUTION". 

(5) Comments will be given in the body of each routine to 
document each subroutine call, Input/output instruction 
and functional grouping of code. 

5.6 SH DEVELOPMENT TOOLS 


It is recommended that, as a minimum, the following types of 
software development tools be utilized In the performance of the SS MPS 
project: 

(1) Virtual memory operating system 

(2) Data Base design aid 

(3) Requirements specification language and analyzer 

(4) Program design language 

(5) Programming support library with CM aids 

(6) Text editor and manager 

Most of the aforementioned types of tools are available in the 
ADA Programming Support Environment developed by the Stoneman project for the 
Department of Defense. In addition, for the expert system prototyping the 
following tools are recommended: 

(1) Expert system development tool 

(2) Natural language development tool 

It is recommended that an in-depth technology survey be 
performed prior to the purchase of any off-the-shelf AI tools. 
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INPUT FILES: SITE DEFNS NDF 
OUTPUT FILES: SITE AC/LOS CVO 
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INPUT FILES: USER MODELS 

USER RSCENV ALLOCS 
OUTPUT FILES: USER MODELS 
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INPUTS. 

INPUT FILES: URDB 

USER ACTIVITY PLANS DB 
OUTPUT FILES: USER CMD PLANS DB 
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SI SW MODULE FUNCTIONAL DESCRIPTION I 



A, B, AND C AND USED AS AN ADVISOR IN SUBFUNCTIONS 8 AND 
10 OF THE REPLANNING CYCLE D. 
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Appendix B 

COCOMO SW Set Cost Estimates 


This appendix contains the COCOMO detailed cost estimate for each SH Set. 
This output was used as the basis for the SS MPS cost estimate. 
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A- SPECIAL OBSERVATION OPPORTUNITIES EXECUTIVES 


OUTPUT SECTION 2 - PHASE DISTRIBUTION 


SOFTWARE PHASE 

EFFORT . 
man-months 

SCHEDULE 

months 

COST 

$ 

AVERAGE 

STAFF 

Plans & Requirements 

28.8 

5.9 

$0 

4.9 

Product Design 

64.7 

5.9 

$0 

10.9 

Programming 

183.3 

5.9 

$0 

31.0 

Integration & Testing 

gg 3KS5 SC SB SS 3S ^5 ^5 SS«^5SSSSe SSBSS 3S5 

111.4 

4.6 

$0 

24.2 

TOTAL 

388.2 

22.4 

$0 

17.4 



OUTPUT SECTION 

3 - ACTIVITY & PHASE 1 

DISTRIBUTION 



• 

SOFTWARE 

PHASES 



SOFTWARE 

Plans & 

Product 


Integration 


ACTIVITIES 

Reqts Design 

Programming 

and Testing 

TOTAL 

Reqts Anlys 

12.65 6.47 

'5.50 

2.23 

26.85 

Product Des 

4.31 

27.18 

11.00 

4.46 

46.95 

Programming 

2.30 

8.41 

100.83 

49.03 

160.58 

Test Ping 

1.44 

4.53 

12.83 

4 .46 

23.26 

V & V 

2.59 

5.82 

20.17 

25.63 

54.21 

Project Off 

2.88 

5.82 

11.00 

7.80 

27.50 

CM/QA 

1.15 

1.94 

12.83 

10.03 

25.95 

Manuals 

SSS^S as XS^S 

1.44 4.53 

9.17 

7.80 

22.93 

TOTAL 

28.76 64.71 

183.34 

111.44 

388.24 


END OF OUTPUT SECTION 3 


PRECEDING 


page BLANK not filmed 
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B- URDB I/F 


OUTPUT SECTION 2 - PHASE DISTRIBUTION 


SOFTWARE PHASE 

EFFORT 

man-months 

SCHEDULE 

months 

COST 

$ 

AVERAGE 

STAFF 

Plans & Requirements 

32.4 

6.1 

$0 

5.3 

Product Design 

72.9 

6.1 

$0 

11.9 

Programming 

206.6 

6.1 

$0 

33.6 

Integration & Testing 

125.6 

4.8 

$0 

26.3 


TOTAL 437.5 23.2 $0 18.8 



OUTPUT SECTION 

3 - ACTIVITY & PHASE : 

DISTRIBUTION 




SOFTWARE 

PHASES 



SOFTWARE 

Plans & 

Product 


Integration 


ACTIVITIES 

Reqts 

Design 

Programming 

and Testing 

TOTAL 

Reqts Anlys 

14.26 

7.29 

6.20 

2.51 

30.26 

Product Des 

4.86 

30.63 

12.40 

5.02 

52.91 

Programming 

2.59 

9.48 

113.63 

55.26 

180.96 

Test Ping 

1.62 

5.10 

14.46 

5.02 

26.21 

V & V 

2.92 

6.56 

22.73 

28.88 

61.09 

Project Off 

3.24 

6.56 

12.40 

8 . 79 

30.99 

CM/QA 

1.30 

2.19 

14.46 

11.30 

29.25 

Manuals 

1.62 

5.10 

10.33 

8.79 

25.85 

TOTAL 

32.41 

72.92 

206.61 

125.58 

437.52 
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C- EDITOR EXECUTIVES 


OUTPUT SECTION 2 - PHASE DISTRIBUTION 


SOFTWARE PHASE 

SS5 S5 SS SS SS SS SS SSS SS 8X 

EFFORT 

man-months 

SCHEDULE 

months 

COST 

$ 

AVERAGE 

STAFF 

Plans & Requirements 
Product Design 
Programming 
Integration & Testing 

11.2 

25.3 
75.8 

39.3 

3.9 

4.1 

4.9 

3.2 

$0 

$0 

$0 

$0 

2.9 

6.1 

15.6 

12.4 

TOTAL 

151.7 

16.1 

$0 

9.4 


OUTPUT SECTION 3 - ACTIVITY & PHASE DISTRIBUTION 


SOFTWARE PHASES 


SOFTWARE 

ACTIVITIES 

Plans & 
Reqts 

Product 

Design 

Programming 

Integration 
and Testing 

TOTAL 

Reqts Anlys 

5.17 

2.53 


2.28 

0.79 

10.76 

Product Des 

1.57 

10.62 


4.55 

1.57 

18.31 

Programming 

0.67 

3.03 


41.71 

15.73 

61.15 

Test Ping 

0.45 

1.52 


4.55 

1.57 

8.09 

V & V 

0.90 

2.02 


7.58 

9.83 

20.34 

Proiect Off 

1.35 

2.78 


5.31 

3.15 

12.58 

CM/QA 

0.45 

0.76 


5.31 

3.54 

10.06 

Manuals 

— i m ymm — 

0.67 

2.02 


4.55 

3.15 

10.39 

TOTAL 

11.24 

25.28 


75.84 

39.33 

151.69 


END OF OUTPUT SECTION 3 


D- RE-SCHEDULER 


OUTPUT SECTION 2 - PHASE DISTRIBUTION 



EFFORT 

SCHEDULE 

COST 

AVERAGE 

SOFTWARE PHASE 

man-months 

months 

$ 

STAFF 

Plans & Requirements 

27.7 

5.8 

$0 

4.7 

Product Design 

62.4 

5.8 

$0 

10.7 

Programming 

176.8 

5.8 

$0 

30.2 

Integration & Testing 

107.4 

4.5 

$0 

23.6 

TOTAL 

374.3 

22.1 

$0 

16.9 



OUTPUT SECTION 

3 - ACTIVITY & PHASE 1 

DISTRIBUTION 




SOFTWARE 

PHASES 



SOFTWARE 

Plans & 

Product 


Integration 


ACTIVITIES 

Reqts 

Design 

Programming 

and Testing 

TOTAL 

ssassasasss 

Reqts Anlys 

12.20 

6.24 

5.30 

2.15 

25.89 

Product Des 

4.16 

26.20 

10.61 

4.30 

45.26 

Programming 

2.22 

8.11 

97.21 

47.27 

154.82 

Test Ping 

1.39 

4.37 

12.37 

4.30 

22 . 42 

V & V 

2.50 

5.61 

19.44 

24.71 

52.26 

Project Off 

2.77 

5.61 

10.61 

7.52 

26.51 

CM/QA 

1.11 

1.87 

12.37 

9.67 

25.02 

Manuals 

1.39 

4.37 

8.84 

7.52 

22.11 

TOTAL 27.73 

62.38 

176.75 

107.44 

374.30 
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E-SYSTEM EXECUTIVES (PHASE I) 


OUTPUT SECTION 2 - PHASE DISTRIBUTION 


SOFTWARE PHASE 

EFFORT 

man-months 

SCHEDULE 

months 

COST 

$ 


AVERAGE 

STAFF 

Plans & Requirements 

28.7 

5.9 


$0 

4.8 

Product Design 

64.5 

5.9 


$0 

10.9 

Programming 

182.7 

5.9 


$0 

30.9 

Integration & Testing 

111.0 

4.6 


$0 

24.2 

TOTAL 

386.8 

22.3 


”5»SS 

$0 

17.3 



OUTPUT SECTION 

3 - ACTIVITY & PHASE : 

DISTRIBUTION 




SOFTWARE 

PHASES 



SOFTWARE 

Plans & 

Product 


Integration 


ACTIVITIES 

SUB35«S^52S2SlB^RflS3S35 

Reqts 

8S9B9B9E9B^SjB2SSff9BflB SB 

Design 

Programming 

and Testing 

TOTAL 

Reqts Anlys 

12.61 

6.45 

5.48 

2.22 

26.75 

Product Des 

4.30 

27.08 

10.96 

4.44 

46.78 

Programming 

2.29 

8.38 

100.46 

48.85 

159.99 

Test Ping 

1.43 

4.51 

12.79 

4.44 

23.17 

V & V 

2.58 

5.80 

20.09 

25.54 

54.01 

Project Off 

2.87 

5.80 

10.96 

7.77 

27.40 

CM/QA 

1.15 

1.93 

12.79 

9.99 

25.86 

Manuals 

1.43 

4.51 

9.13 

7.77 

22.85 

TOTAL 

28.65 

64.47 

182.66 

111.03 

386.81 


» END OF OUTPUT SECTION 3 


B-7 


F- SYSTEM EXECUTIVES (PHASE II) 


OUTPUT SECTION 2 - PHASE DISTRIBUTION 


SOFTWARE PHASE 

EFFORT 

man-months 

SCHEDULE 

months 

COST 

$ 

AVERAGE 

STAFF 

Plans & Requirements 

46.1 

6.9 

$0 

6.7 

Product Design 

103.7 

6.9 

$0 

15.1 

Programming 

293.9 

6.9 

$0 

42.7 

Integration & Testing 

178.7 

5.4 

$0 

33.4 

TOTAL 

622.4 

26.0 

$0 

23.9 



OUTPUT SECTION 

3 - ACTIVITY & PHASE 

DISTRIBUTION 




SOFTWARE 

PHASES 



SOFTWARE 

Plans & 

Product 


Integration 


ACTIVITIES 

Reqts 

Design 

Programming and Testing 

TOTAL 

Reqts Anlys 

20.29 

10.37 

8.82 

3.57 

43.05 

Product Des 

6.92 

43.57 

17.64 

7.15 

75.27 

Programming 

3.69 

13.49 

161.66 

78.61 

257.45 

Test Ping 

2.31 

7.26 

20.57 

7.15 

37.29 

V & V 

4.15 

9.34 

32.33 

41.09 

86.91 

Project Off 

4.61 

9.34 

17.64 

12.51 

44.09 

CM/QA 

1.84 

3.11 

20.57 

16.08 

41.61 

Manuals 

ssss ssssssss 

2.31 

7.26 

14.70 

12.51 

36.77 

TOTAL 

46.11 

103.74 

293.93 

178.66 

622.43 
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G-COMMAND PLANNER 


OUTPUT SECTION 2 - PHASE DISTRIBUTION 


SOFTWARE PHASE 

EFFORT 

man-months 

SCHEDULE 

months 

COST 

$ 

AVERAGE 

STAFF 

Plans & Requirements 

5.0 

3.0 

$0 

1.7 

Product Design 

11.2 

3.2 

$0 

3.5 

Programming 

33.7 

3.8 

$0 

9.0 

Integration & Testing 

17.5 

2.4 

$0 

7.2 

TOTAL 

67.3 

12.4 

$0 

5.4 


OUTPUT SECTION 3 - ACTIVITY & PHASE DISTRIBUTION 

SOFTWARE PHASES 


SOFTWARE 

ACTIVITIES 

8SSSSSBS8B3B8SSSS8SaBSSSCS8 

Plans & 
Reqts 

Product 

Design 

Programming 

Integration 
and Testing 

TOTAL 

Reqts Anlys 

* 2.29 

1.12 


1.01 

0.35 

4.78 

Product Des 

0.70 

4.71 


2.02 

0.70 

8.13 

Programming 

0.30 

1.35 


18.51 

6.98 

27.14 

Test Ping 

0.20 

0.67 


2.02 

0.70 

3.59 

V & V 

0.40 

0.90 


3.37 

4.36 

9.03 

Project Off 

0.60 

1.23 


2.36 

1.40 

5.59 

CM/QA 

0.20 

0.34 


2.36 

1.57 

4.46 

Manuals 

0.30 

0.90 


2.02 

1.40 

4.61 

TOTAL 

4.99 

11.22 


33.66 

17.45 

67.32 


END OF OUTPUT SECTION 3 « 
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H-NEW CONVENTIONAL TIMELINE SOFTWARE 


OUTPUT SECTION 2 - PHASE DISTRIBUTION 


SOFTWARE PHASE 

EFFORT 

man-months 

SCHEDULE 

months 

COST 

$ 

AVERAGE 

STAFF 

Plans & Requirements 
Product Design 
Programming 
Integration & Testing 

36.9 

83.0 

235.2 

143.0 

6.4 

6.4 

6.4 

5.0 

$0 

$0 

$0 

$0 

5.8 

13.0 

36.7 

28.7 

TOTAL 

498.1 

24.2 

$0 

20.6 


OUTPUT SECTION 3 - ACTIVITY & PHASE DISTRIBUTION 

SOFTWARE PHASES 


SOFTWARE 

ACTIVITIES 


Reqts Anlys 
Product Des 
Programming 
Test Ping 
V & V 

Project Off 

CM/QA 

Manuals 


TOTAL 


Plans & 
Reqts 

Product 

Design 

Integration 
Programming and Testing 

TOTAL 

16.23 

8.30 

7.06 

2.86 

34. 

45 

5.53 

34.87 

14.11 

5.72 

60. 

23 

2.95 

10.79 

129.36 

62.91 

206. 

01 

1.84 

5.81 

16.46 

5.72 

29. 

84 

3.32 

7.47 

25.87 

32.88 

69. 

55 

3.69 

7.47 

14.11 

10.01 

35. 

28 

1.48 

2.49 

16.46 

12.87 

33. 

30 

1.84 

5.81 

11.76 

10.01 

29. 

42 

K3X3SSS 

36.89 

83.01 

235.20 

142.97 

498. 

08 


! 
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I -MODIFIED TIMELINE SW 


OUTPUT 

SECTION 2 

- PHASE DISTRIBUTION 




EFFORT 

SCHEDULE 

COST 


AVERAGE 

SOFTWARE PHASE man-months 

months 

$ 


STAFF 

Plans & Requirements 

34.6 

6.3 


$0 

5.5 

Product Design 

77.8 

6.3 


$0 

12.4 

Programming 

220.5 

6.3 


$0 

35.1 

Integration & Testing 

134.0 

4.9 


$0 

27.5 

TOTAL 

467.0 

23.7 


$0 

19. T 


OUTPUT SECTION 3 - ACTIVITY & PHASE DISTRIBUTION 


SOFTWARE PHASES 


SOFTWARE 

ACTIVITIES 

Plans & 
Reqts 

Product 

Design 

Integration 
Programming and Testing 

TOTAL 

Reqts Anlys 

15.22 

7.78 

6.62 

2.68 

32.30 

Product Des 

5.19 

32.69 

13.23 

5.36 

56.47 

Programming 

2.77 

10.12 

121.28 

58.98 

193.15 

Test Ping 

1.73 

5.45 

15.44 

5.36 

27.98 

V & V 

3.11 

7.00 

24.26 

30.83 

65.20 

Project Off 

3.46 

7.00 

13.23 

9.38 

33.08 

CM/QA 

1.38 

2.33 

15.44 

12.06 

31.22 

Manuals 

1.73 

5.45 

11.03 

9.38 

27.59 

TOTAL 

34.59 

77.83 

220.52 

134.04 

466.98 
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J-MODIFIED ORBIT ANALYSIS SW 


OUTPUT SECTION 2 - PHASE DISTRIBUTION 


SOFTWARE PHASE 

EFFORT 

man-months 

SCHEDULE COST 

months $ 


AVERAGE 

STAFF 

Plans & Requirements 

9.1 

3.6 

$0 

2.5 

Product Design 

20.5 

3.9 

$0 

5.3 

Programming 

61.6 

4.6 

$0 

13.5 

Integration & Testing 

31.9 

3.0 

$0 

10.3 

TOTAL 

123.1 

15.0 

$0 

8.2 



OUTPUT SECTION 

3 - ACTIVITY & PHASE ! 

DISTRIBUTION 




SOFTWARE 

PHASES 



SOFTWARE 

Plans & 

Product 


Integration 


ACTIVITIES 

Reqts 

Design 

Programming 

and Testing 

TOTAL 

Reqts Anlys 

4.20 

2.05 

1.85 

0.64 

8.73 

Product Des 

1.28 

8.62 

3.69 

1.28 

14.87 

Programming 

0.55 

2.46 

33.86 

12.77 

49.64 

Test Ping 

0.36 

1.23 

3.69 

1.28 

6.57 

V & V 

0.73 

1.64 

6.16 

7.98 

16.51 

Project Off 

1.09 

2.26 

4.31 

2.55 

10.21 

CM/QA 

0.36 

0.62 

4.31 

2.87 

8.16 

Manuals 

0.55 1.64 

3.69 

SRSSS^S^SSSSBSSSSSS 32 

2.55 

SB^B 223 S3 SftS^SSS S52S 5S 

8.44 

— 55SS 32 33 3S S 2 S3 2 

TOTAL 

9.12 20.52 

61.56 

31.92 

123.13 
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K-MODIFIED DATA FLOW SW 


i r 

! i 

i 


OUTPUT SECTION 2 - PHASE DISTRIBUTION 


SOFTWARE PHASE 

EFFORT 

man-months 

SCHEDULE 

months 

COST 

$ 

AVERAGE 

STAFF 

Plans & Requirements 

46.3 

6.9 

$0 

6.7 

Product Design 

104.2 

6.9 

$0 

15.1 

Programming 

295.2 

6.9 

$0 

42.8 

Integration & Testing 

179.4 

5.4 

$0 

33.5 

TOTAL 

625.1 

26.0 

$0 

24.0 


r 


SOFTWARE 

ACTIVITIES 

OUTPUT SECTION 

3 - ACTIVITY & PHASE 
SOFTWARE PHASES 

DISTRIBUTION 

TOTAL 

Plans & 
Reqts 

Product 

Design 

Integration 
Programming and Testing 

Reqts Anlys 

20.37 

10.42 

8.86 

3.59 

43.24 

Product Des 

6.95 

43.76 

17.71 

7.18 

75.59 

Programming 

3.70 

13.54 

162.36 

78.95 

258.56 

Test Ping 

2.32 

7.29 

20.66 

7.18 

37.45 

V & V 

4.17 

9.38 

32.47 

41.27 

87.29 

Project Off 

4.63 

9.38 

17.71 

12.56 

44.28 

CM/QA 

1.85 

3.13 

20.66 

16.15 

41.79 

Manuals 

2.32 

saBssssssBBsns atH 

7.29 

14.76 

12.56 

36.93 

TOTAL 

46.31 

104.19 

295.20 

179.44 

625.13 
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L-OUTPUT PROCESSOR EXECUTIVE 


OUTPUT SECTION 2 - PHASE DISTRIBUTION 

EFFORT SCHEDULE COST AVERAGE 


SOFTWARE PHASE 

man-months 

months 

$ 

STAFF 

Plans & Requirements 

3.7 

2.7 

$0 

1.4 

Product Design 

8.4 

2.9 

$0 

2.9 

Programming 

25.1 

3.4 

$0 

7.3 

Integration & Testing 

13.0 

2.2 

$0 

5.9 

TOTAL 

50.2 

11.3 

$0 

4.5 



OUTPUT SECTION 

3 - ACTIVITY & PHASE 

DISTRIBUTION 




SOFTWARE 

PHASES 



SOFTWARE 

Plans & 

Product 


Integration 


ACTIVITIES 

Reqts 

Design 

Programming and Testing 

TOTAL 

BSSSSrTTTgSS . .T^rfTTSa 

Reqts Anlys 

1.71 

0.84 

0.75 

0.26 

3.56 

Product Des 

0.52 

3.51 

1.51 

0.52 

6.06 

Programming 

0.22 

1.00 

13.80 

5.21 

20.24 

Test Ping 

0.15 

0.50 

1.51 

0.52 

2.68 

V & V 

0.30 

0.67 

2.51 

3.25 

6.73 

Project Off 

0.45 

0.92 

1.76 

1.04 

4.16 

CM/QA 

0.15 

0.25 

1.76 

1.17 

3.33 

Manuals 

0.22 

0.67 

1.51 

1.04 

■ atiBsssiwaBBSsa 

3.44 

TOTAL 

3.72 

8.37 

25.10 

13.01 

50.20 


END OF OUTPUT SECTION 3 


B-14 


